2026.10.20

Webアプリケーション脆弱性診断の診断項目はどう決まるのか ― MBSDの策定プロセス

著者：望月岳

その他

Webアプリケーション脆弱性診断の診断項目はどう決まるのか ― MBSDの策定プロセス

はじめに

弊社は、前身のE3ネットワークス株式会社を設立した2001年からWebアプリケーション脆弱性診断サービスを開始し、今年で25周年を迎えました。

その間、Webアプリケーションを取り巻く環境は年々変化し、それにあわせて脆弱性診断サービスの診断項目も進化してきました。

今回のブログでは、弊社が提供しているWebアプリケーション脆弱性診断サービスにおいて、どのようなプロセスを経て診断項目を決定しているかを、簡単にではありますが紹介させていただきます。

このようなプロセスが公開されることはあまりないため、診断項目やセキュリティ要件を決定する立場の方々にとっては気になる点ではないでしょうか。

基本方針

弊社が提供しているWebアプリケーション脆弱性診断サービスでは、セキュリティ関連の業界団体や政府機関等が公表している文書で定義・推奨されている項目を基に、脆弱性診断の品質管理を担うチームによって最適な診断項目や基準を協議したうえで、弊社独自の診断項目を策定する方針にしています。

特定のガイドラインに完全準拠（遵守）するのではなく、このような方針にしている主な理由は以下の3つです。

技術に沿った脆弱性診断が行えるようにする

Webアプリケーションを構成する技術（開発言語やフレームワーク、プラットフォーム、プロトコル）やWebセキュリティ関連の規格、ブラウザに備わる機能は年々進化しており、早いスピードで新しい技術が生まれています。そして、それに伴い攻撃者も進化し、新たな攻撃手法や脆弱性が公表されています。

しかし、セキュリティ関連の業界団体や政府機関等が公表する文書は常に最新の情報を追従できているわけではなく、新たな技術に関する情報が反映されるまでに一定の遅れが生じてしまいます。

このため、最新の技術を用いて構築されたWebアプリケーションに対しても適切な検証を実施して脆弱性を洗い出せるように、ガイドラインの要求事項以外についても目を配り、技術に沿った診断項目を作る必要があると考えています。

優先度の低い要求事項を除外する

セキュリティ関連の業界団体や政府機関等が公表する文書での要求事項は、一定の汎用性があるものになっているものの、中には必須要件と判断しにくい要求事項が含まれています。

必須か否かはシステムが提供しているサービスや取り扱う情報の機密レベル、要求するセキュリティレベルに応じて事業者自らで判断が必要なものの、過去にOWASP ASVSで定義されていた以下のような要求事項については、不要と判断されるケースも多いのではないでしょうか。
例えば、OWASP ASVS 4.0では、以下のような要求事項があります。

項目	項番	説明
V2.1 パスワードセキュリティ	2.1.8	ユーザがより強力なパスワードを設定できるように、パスワード強度メータが用意されている。

※引用元: OWASP-JA / ASVS-JA: OWASP アプリケーションセキュリティ検証標準 4.0 邦訳版 / V2 認証

本項目は、パスワードの設定や変更画面において、パスワードとして使用する文字列の強度をユーザに可視化する機能の実装を推奨する項目です。同様の項目は脆弱性診断士スキルマッププロジェクトが公開しているWebシステム／Webアプリケーションセキュリティ要件書でも定義されています。

パスワード強度メータにより、ユーザに強力なパスワードの設定を促すことができます。しかし、昨今はパスワード生成及び記憶を人に任せるのではなく、ブラウザやOSに備わるパスワードマネージャーに任せることで安全にパスワード管理できる状況が整いつつあります。また、パスワードではなくPassKeyを使うサイトも増えてきています。

この状況を考慮すると、パスワード強度メータは今後不要になる可能性も考えられるのではないでしょうか。

上記は一例ではありますが、容易に検証可能な項目であるため診断項目として採用することは何ら難しくありません。しかし、弊社では本当に必要な項目か否か、優先的に対策していただくべき項目か否かを品質管理チーム内で協議したうえで、採否を判断します。

Webアプリケーションの脆弱性診断では検証できない項目を除外する

一般的なWebアプリケーションの脆弱性診断は、テスト・本番問わず稼働しているWebアプリケーションに対して疑似的な攻撃を行ったり（ブラックボックステスト）、ソースコードを精査してセキュリティ上の不備を探したり（ホワイトボックステスト）といった手法で行われます。

疑似的な攻撃とソースコードの精査を合わせた手法（グレーボックステスト）もありますが、いずれのテスト手法もWebアプリケーションの実装フェーズ以降の成果物（稼働中のWebアプリケーションやソースコード）に対して実施します。

このため、例えば設計書等のドキュメントに記載された情報を確認する必要がある項目、インフラの設定を確認する必要がある項目などは脆弱性診断で検証することは困難です。

しかし、OWASP ASVSなどの文書ではシステムの安全を担保するための包括的なセキュリティ事項が定義されているため、そういった脆弱性診断では検証できない項目も含まれています。

具体例を挙げると、OWASP ASVS 5.0の以下のような項目がそれにあたります。

項目	項番	説明
V2.1 バリデーションとビジネスロジックドキュメント	2.1.3	ビジネスロジックの制限とバリデーションに対する期待は、ユーザーごと、およびアプリケーション全体にわたって文書化されている。
V16.1 セキュリティログ記録ドキュメント	16.1.1	アプリケーションのテクノロジスタックの各レイヤで実行されるログ記録、ログ記録されるイベント、ログ形式、ログ記録の保存場所、ログ記録の使用方法、ログ記録へのアクセスコントロール方法、ログの保存期間を文書化したインベントリが存在している。

※引用元: OWASP-JA / ASVS-JA: OWASP アプリケーションセキュリティ検証標準 5.0 邦訳版

ASVSだけでなく、TOP 10などにも脆弱性診断という枠組みでは検証が難しい項目が含まれています。
このため、弊社では形式的に網羅するのではなく、実際の診断で検証可能且つ有効な観点を選定したうえで、診断項目を策定しています。脆弱性診断では検証が難しい項目については、お客様の要望をヒアリングしたうえで設計レビューやサーバ構成診断といった別メニューをご案内したり、脆弱性診断のオプションとして対応したりしております。

なお、一部のベンダーでは脆弱性診断においてOWASP ASVSやOWASP TOP 10の網羅をうたっているようなケースがあるため、ベンダーに依頼する際は診断手法や診断項目などをご確認することをお勧めいたします。

診断項目の策定プロセス

弊社では、Webアプリケーションの脆弱性診断項目を策定するにあたり、以下のような作業を実施しております。

「情報収集」及び「収集した情報の整理」は日常的に実施していますが、大きな改定は1～2年に一度のサイクルで実施しています。

ただし、影響の大きな攻撃手法や脆弱性が公表されたり、既にインシデントが多発しており注意喚起が行われたりした場合など、幾つかの条件を満たした場合は改定のタイミングを待たず診断項目を追加することがあります。

直近では、インターネット取引サービスにおいて不正アクセスによる口座乗っ取りが多発したことに伴い、日本証券業協会から多要素認証の設定を推奨する注意喚起(*1)が公表されました。

これに伴い、弊社ではオンライン証券やインターネットバンキング等のサービスを提供するWebアプリケーションに限り多要素認証の実装を必須要件と定義し、多要素認証機能が存在するか否かを確認する診断項目を策定しました。

*1) 当初は「多要素認証（ワンタイムパスワード等、2要素以上を組み合わせる認証）」を推奨する注意喚起でしたが、2026年3月25日に「フィッシングに耐性のある多要素認証（パスキーによる認証等）」を推奨する内容に変更されています。

このように日頃から情報を収集し、必要性や影響度を鑑みて診断項目を継続的に見直すことで、お客様のシステムが最新の脅威に対して適切に対策されているかを診断できる状況を整えています。

次項では、前述の各作業に関して詳しく説明します。

情報収集

前述のとおり、弊社では様々な文書で定義されたセキュリティ要件を参考にWebアプリケーション脆弱性診断の診断項目を作成しているため、まずは情報収集を行います。

主に診断の品質管理チームのメンバーが中心となり、日常的に以下のような項目に関する情報を収集しています。

▼主な項目

追加すべき診断項目
廃止を検討すべき診断項目
指摘基準の変更が必要となる項目
診断手法や手順の更新が必要な項目
新たな攻撃手法

これといって特別な項目はありませんが、過去に定義されていた項目が廃止されたり、安全と判断する基準が変更されたりすることもあるため、追加項目のみを調査するのではなく既出の診断項目に対する変更の有無なども確認しています。

以下に、診断項目を策定する際に参考にしている情報収集源をまとめました。

▼主な情報収集源

Webセキュリティ関連の業界基準やガイドライン
- OWASP
  - Web Security Testing Guide
    Webアプリケーションの脆弱性検出手法およびテスト項目を体系化した文書です。ペイロードの網羅性は低いものの、具体的な説明とペイロード例が記載されているため、初学者の学習教材や開発者自身が簡易な検証を行う際の参考資料として有用です。
    
    なお、OWASPのページで公開されているStableバージョンは5年以上前の情報ですが、本プロジェクトのリポジトリでメンテナンス中の最新の情報を確認できます。
  - Application Security Verification Standard
    WebアプリケーションおよびAPIなどの各機能領域における17のセキュリティ要件カテゴリを定義し、アプリケーションのビジネスリスク（データの機密性、侵害時の影響度、システムの重要度）に基づいて、3段階のセキュリティ成熟度レベルを適用するフレームワークです。
  - Top 10
    Webアプリケーションのセキュリティに関する重大リスクのトップ10を定めたものです。
    不定期で見直しが行われており、話題になったインシデントで悪用された脆弱性や、報告が急増した脆弱性などその時々の状況を考慮して選定されるため、実情に沿った内容になっています。
    昨年4年ぶりに更新され、2026年1月にはOWASP Japan Chapterによって日本語翻訳版がリリースされました。
  - API Security Top 10
    前述のTop 10はWebアプリケーション向けの内容となっているのに対し、API Securityはその名の通りWeb API特有のセキュリティに関する重大リスクのトップ10を定めたものです。
- ISOG-J（日本セキュリティオペレーション事業者協議会）
  - Webシステム / Webアプリケーションセキュリティ要件書
    脆弱性診断やペネトレーションテストに関わるベンダーのエンジニアによって作成された、Webアプリケーションを設計/開発/運用する上で最低限満たしておくべきセキュリティ要件を定義した文書です。
    弊社でフェローを務める国分やペネトレーションテストや脆弱性診断に携わるメンバーも執筆に携わっています。
  - Webアプリケーション脆弱性診断ガイドライン
    Webアプリケーションの脆弱性診断に求められる最低限の診断項目や診断手法を定義した文書です。
    スキャンツールの品質や診断員のスキルに依存することなく、一定レベルの手動診断を行えることを目指して作成されたものです。
  - 細かすぎるけど伝わってほしい脆弱性診断手法ドキュメント
    Webアプリケーションの脆弱性のうち、検証方法や手順が特殊なものにフォーカスして診断手法をまとめた文書です。
- 政府機関や関連団体などが公表するガイドライン
  個別の説明は省略させていただきますが、国内外の政府機関や社団法人等が公表するセキュリティや認証、本人確認、決済等に関するガイドラインを参考にしています。
  - デジタル庁
    - DS-221 政府情報システムにおける脆弱性診断導入ガイドライン
    - DS-500 行政手続等におけるトラストおよびデジタルアイデンティティに関するガイドライン群
  - 経済産業省
    - クレジットカード・セキュリティガイドライン
  - 一般社団法人キャッシュレス推進協議会
    - コード決済における不正流出したクレジットカード番号等の不正利用防止対策に関するガイドライン
    - コード決済における不正な銀行口座紐づけの防止対策に関するガイドライン
  - 一般社団法人OpenIDファウンデーション・ジャパン
    - 民間事業者向けデジタル本人確認ガイドライン
  - National Institute of Standards and Technology
    - NIST SP 800-63 Digital Identity Guidelines
  - PCI-SSC
    - PCI DSS
- Web関連のセキュリティ規格やクライアント（ブラウザ）に関する情報
  クライアントを取り巻くセキュリティの規格や機能などについては、Web技術の標準化を行う非営利団体（w3c）が公表している文書やブラウザベンダーが公表しているブラウザのリリースノートを参照して最新の情報を収集しています。
  - セキュリティ規格
    - w3c / Web Application Security Working Group
  - ブラウザ関連
- セキュリティカンファレンスの資料
  - 主なセキュリティカンファレンス
    - Black Hat
    - Defcon
    - RSA Conference
    - OWASP
    - CODEBLUE
- 既知脆弱性やインシデントに関する情報、バグバウンティのWrite-up等
  日々様々な脆弱性やインシデントに関する情報、バグバウンティのWriteupなどが公表されているため、その中から主に以下のような情報をピックアップして確認しています。
  - 利用者数が多い著名なソフトウェアやフレームワークに関する脆弱性情報
  - SNS上で話題になっている脆弱性情報
  - 国内外のセキュリティエンジニアがブログやSNSで公開する情報

このほか、日々お客様と様々なやり取りをしているプロジェクトマネージャーや診断員にも意見を求め、品質管理チームが認識できていない潜在的な要望や改善項目を洗い出します。

お客様から頂く診断項目に関する要望や質問
プロジェクトマネージャーや診断員が考える診断項目の改善事項や要望
過去の診断において、リスク評価や報告の要否に悩んだ項目

このような情報収集源から集めた様々な情報は整理したうえでチームに共有しています。

また、OWASPのASVS、Top 10、API Security Top 10などはお客様がセキュリティ要件を定義する際の参考にしているケースが多いほか、ベンダーに脆弱性診断を依頼する際に必須の診断項目として挙げられることがあるため、これらの文書が更新されたタイミングで弊社の脆弱性診断サービスにおける対応状況をマッピングする作業も別途行っております。

収集した情報の整理

収集した情報の中からチームで協議すべき項目を整理することで、品質管理チームでスムーズに協議が行えるようにします。

基本的には品質管理チームで共有している情報管理用シートに各々が記入する形で運用していますが、速やかな対応が求められる項目に関しては合わせてチームのグループチャットで情報共有のうえ協議を進めます。

情報を整理するにあたり、ただ項目や概要を列挙するだけではなく、以下のような付随情報も記録します。

このような付随情報を含めることにより、他のメンバーが当該項目を把握しやすくし、速やかに議論に移れるように努めています。

▼整理する項目

診断項目の概要
診断項目の詳細
- 目的
- 策定・変更の経緯
- 診断手順や手法
- 情報元（当該項目を定義した団体及び文書、社内からの起案である場合は起案者名等）
起案理由
懸念事項
- 診断対象に与える影響（安全に検証可能か否か）
- 既存の診断項目や他のガイドラインとの整合性
- 内製ツールでの対応要否
- 根本的対策の有無や対策に要するコスト
- 対策による弊害の有無

この中で特に重要な項目が、目的と経緯 です。全ての文書でこれらが公表されているわけではないものの、当該項目がどのような理由で追加・更新されるに至ったかを把握することができるため、診断項目として採用するか否かを判断する際の重要な要素の一つです。

特にOWASPが公開している文書については、Githubにおいてオープンな形で有識者が議論して決定されるケースがあり、経緯を把握できるため非常に参考になります。

例えば、モダンなWebアプリケーションではJWT（JSON Web Token）をAuthorizationヘッダに設定する方法でセッション管理を行うケースが増えていますが、"クライアントとしてブラウザを用いる場合、どのように（どこに）JWTを保存するべきか" という議論がXやナレッジ共有サイト上で行われることがありました。

同様の議論はOWASPのASVSプロジェクトでも行われており、それについて説明するとブログをもう一つ書ける程度の文量になってしまうため、詳細はASVSプロジェクトのIssue #843をご参照ください。

このような情報を参照することにより、経緯を把握するだけでなく世の中のセキュリティエンジニアや開発者の様々な意見を知ることができるため、自身の思考の整理や考慮漏れの有無等を確認することができます。

採否の協議

弊社では、各文書で定義された診断項目・セキュリティ要件を鵜呑みにしてサービスに取り込むのではなく、整理した情報を基にチームでミーティングを実施して各項目について協議します。

脆弱性診断の経験者である診断チームのマネージャーが最終的な判断権者として参加し、その他には長年脆弱性診断やペネトレーションテストなどの業務に従事している品質管理チームのメンバーや診断員で構成されています。

採否の協議では、前述の作業でまとめた情報を基に、追加が推奨される項目や既存の指摘基準の変更が推奨される項目、既存の項目から除外すべき項目の3点について議論を行います。

そして、基本的には出席者全員の合意をもって採否を決定します。しかし、項目によっては意見が割れることもあるため、そのような場合はそれぞれの主張をまとめたうえで診断チームのマネージャーに最終判断を仰いで採否を決定します。

▼追加候補の項目を検討する際の観点

Webアプリケーションに対する脆弱性診断において、検証可能な項目であるか
ブラックボックステスト方式で検証する場合、対象システムやシステムの利用者に悪影響を及ぼさず非破壊で安全に検証可能であるか
検証する目的や必要性について納得できるか
他の組織が公表するガイドラインと整合性がとれているか
システムのセキュリティ向上、攻撃の被害軽減等につながるか
当該項目を対策した場合、利便性が著しく損なわれるなどの弊害はないか

▼報告基準の変更候補の項目を検討する際の観点

報告基準の変更理由について納得できるか
報告基準を変更した場合、他の検証項目に影響を与えることがないか
他の組織が公表するガイドラインと整合性がとれているか
システムのセキュリティ向上、攻撃の被害軽減等につながるか

▼除外候補の項目を検討する際の観点

当該項目の検証・報告を止めたとしても、システムの機密性・完全性・可用性に大きな影響を与えることがないか
既にクライアント側でサポートが終了している機能や技術に関する項目であるか
クライアント側においてセキュリティ上好ましくない状況に限り、影響を受ける事象であるか
- サポートが終了したクライアントソフトウェア（ブラウザ等）を利用している場合のみ影響を受ける
- Webアプリケーションの利用者自身が危険な行動（意図的にセキュリティレベルを下げる設定を行う、セキュリティの警告を無視するなどの操作）をした場合にのみ影響を受ける

実際に過去の診断項目の改定において検討した項目と採否の理由を以下に例示します。

追加した項目

▼CookieのSameSite属性に関する検証

本項目は、Cookieの属性のひとつであるSameSiteに関するものです。SameSiteに関する説明は過去の弊社ブログに記載しておりますので、そちらをご覧ください。

一言で簡潔に説明すると、ブラウザがサイトを跨いでリクエストを送信する際にCookieの送出を制御するために用いる属性です。

この属性は、"Lax"や"Strict"といった属性値に応じてCookieの送出を制限できるため、一部の受動的攻撃を防ぐメリットを享受することができます。

しかし、"None"という属性値を指定した場合はCookieの送出が制限されないため、受動的攻撃の影響を受けるおそれがあります。

弊社では、2022年にSameSite属性の属性値について検証を行うべきか否かを検討し、同年6月以降の案件から検証を開始しました。

そして、属性値において"None"が明示的に指定されている場合はお客様に"Info"という危険度で報告しています。

[追加理由]

本項目の採否を検討したタイミングで、主要なモダンブラウザにおいてSameSite属性がサポートされていたため、積極的にSameSite属性を活用できる状況が整ったと判断した
SameSite属性を適切に用いることにより受動的攻撃の被害の減少が期待でき、利用者及び事業者双方のメリットになるため、本項目を検証することが望ましいと判断した

報告基準を変更した項目

▼パスワード設計の不備（パスワードに使用できる文字列の制限）

本項目は、パスワードとして使用する文字列の設計に関するものです。
従来、弊社の脆弱性診断においてパスワード設計の不備を検証する際、文字種に関しては「使用可能な文字種を制限しているか否か」という観点で検証を実施しており、例えば記号を使えない状況が確認できた場合は、"Info"として報告していました。
この基準は、ISOG-Jの「Webシステム／Webアプリケーションセキュリティ要件書」を参考にして定めたものです。

項目	項番	要件	備考
パスワード	1.3.3	パスワード⽂字列として使⽤可能な⽂字種は制限しないこと	任意の⼤⼩英字、数字、記号、空⽩、Unicode⽂字など任意の⽂字が利⽤可能である必要があります。

※引用元： Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0

しかし、NISTが2025年7月に公表したSP 800-63B-4では、構成規則に関するルールが追加されました。

項目	項番	要件
Password Verifiers	3.1.1.2-5	原文： Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords 日本語訳：検証者および認証サービスプロバイダーは、パスワードに対して他の構成規則（例：異なる文字種の混合を要求すること）を課してはならない。

※引用元: Digital Identity Guidelines Authentication and Authenticator Management

当該文書の添付資料において、パスワードの要件を変更した理由に関して以下のような説明があります。

項目

説明

Strength of Passwords / A.3.Complexity

原文：
research has shown that users respond in very predictable ways to the requirements imposed by composition rules. For example, a user who might have chosen “password” as their password would be relatively likely to choose "Password1" if required to include an uppercase letter and a number or "Password1!" if a symbol is also required.

日本語訳：
研究によれば、ユーザーは構成ルールによって課される要件に対して非常に予測可能な方法で対応することが示されている。例えば、「password」をパスワードとして選択した可能性のあるユーザーは、大文字と数字を含むことが要求された場合「Password1」を、記号も要求された場合「Password1!」を選択する可能性が比較的高い。

つまり、構成規則を課したとしてもユーザ自身がパスワード文字列を設定する場合は容易に推測できる文字列を設定する可能性があり、構成ルールの強制が強度向上につながるとは限らないということです。
これを受け、弊社ではパスワード設計に関する報告基準の見直しを行いました。従来パスワード文字列の文字種が制限されていた場合はその旨を報告しましたが、現在は文字種の制限に加えて、文字種の組み合わせを強制していた場合も不適切であると判断し、その旨を報告しています。

[変更理由]

NIST SP800-63Bの改定内容及び根拠を確認し、上記要件を考慮するのが望ましいと判断した
今後OSやブラウザに備わるパスワードマネージャーの活用が進むと考えられるものの、構成規則の強制が原因でパスワードマネージャーによって生成された文字列が弾かれてしまうことがある。よって、安全性だけでなく利便性にも影響を与えることから、構成規則の強制は不適切であると判断した

除外した項目

▼Flashが関連する脆弱性の検証

Flashは、デスクトップやブラウザ上でアニメーション・音声・動画・ゲームなどのコンテンツを作成・配信するためのプラットフォームです。筆者を含む現在30代後半～50代のインターネット老人会に該当する世代にとっては、とても懐かしさを感じる技術の一つではないでしょうか。

デスクトップアプリケーションとして利用できるだけでなくFlash Playerというプラグインを介してブラウザ上でも利用できたため、Webページに実装されたJavaScriptをFlashから呼び出したり、外部ドメイン上に配置したWebアプリケーションと連携したりといったことも可能でした。
このため、セキュリティを意識せずに開発していた場合、「Cross-Site Flashing（XSF）」や「クロスドメインのアクセス制御不備（crossdomain.xml）」などの脆弱性を作り込んでしまうことがありました。

一時期はFlashを用いた様々なコンテンツがインターネット上で公開されていましたが、Flashを動作させるためのソフトウェアにおいて脆弱性が頻出したほか、HTMLやJavaScriptの進化によりFlashを使わず同程度の機能を実装できるようになった、など様々な理由で衰退が進みました。その結果、2020年末でサポートが終了し、現在では使われない技術となりました。
弊社ではこのような経緯を考慮し、2022年にFlashが関連する脆弱性の検証を診断項目から除外しました。

[除外理由]

Flashの開発元であるベンダー（Adobe）がサポートを終了した
主要なブラウザベンダーでは、Flash Playerをデフォルトでブロックした後にサポートを終了した
上記状況を鑑みるに、WebアプリケーションにおいてFlashを利用しつづけることは考えにくい。また、クライアント側でFlashが動かないのであれば脆弱性があっても悪用できないため、診断項目から除外しても問題ないと判断した

上記はほんの一例で、その年によって議題に挙がる項目数は増減するものの、1～2年の間で40件以上蓄積されるため、1度の改定で複数回のミーティングを重ねて採否を決定しています。
なお、新規追加や変更項目については、あわせて報告時の危険度評価、報告基準、診断手順なども協議しています。

新項目でサービスを提供するための準備

診断項目に関する協議が全て終了した後に、改定のタスクを取り仕切る品質管理チームの担当者は新しい診断項目でサービスを提供するための準備を行います。

診断手法や指摘基準の整理
成果物（速報や報告書）のテンプレート作成
社内向けの説明資料作成
診断業務に従事するメンバーへの説明

これらを個別に説明したいところではありますが、ここまでの内容で長い記事になってしまったので、簡潔にご説明します。

弊社にはWebアプリケーションの脆弱性診断に従事する診断員が多数在籍しているため、業務を標準化して全員が同じ品質で安定的にサービス提供できるよう努める必要があります。
また、診断員自身が新しい項目をお客様に説明できるレベルで理解して作業に従事することが望ましいと考えています。

このため、以下の情報を含む資料やテンプレートを用意したうえで説明会を実施し、新しい項目でのサービス提供に備えています。

追加・変更・削除した診断項目
追加・変更・削除の理由
関連するガイドライン
診断作業に関する情報（手順や手法、ペイロード）
診断時の注意事項
報告する際に用いるテンプレート

このような取り組みを経て、採否の協議からおおよそ1～2か月後に新しい診断項目でのサービス提供を開始します。

なお、新しい診断項目のリリース直後は、当該項目を適切に検証できているか、想定していなかった不整合が起きていないか等を品質管理チームのメンバーが重点的に確認し、不備が見つかれば直ぐに改善できるように努めています。

終わりに

今回は弊社が提供するWebアプリケーションの脆弱性診断の診断項目に対する考え方、診断項目の策定プロセスをご説明させていただきました。

診断項目の採否基準や考え方は、我々と同様に脆弱性診断サービスを提供しているベンダー間でも異なる部分があります。また、自社でプロダクトを開発・提供しており、診断サービスを利用したり内製化したりしている事業者様が診断項目やセキュリティ要件を策定する場合、提供しているサービス / 取り扱う情報の機密レベル / 要求するセキュリティレベル等に応じて採否の基準が変わるものと思われます。

このため、標準メニューでは検証していない項目も含めてほしい、特定の項目を除外してほしい、特定のガイドラインを遵守してほしいといったお客様の要望に応じてカスタマイズしてサービスをご提供することも可能です。

また、弊社のこれまでの知見を活かし、脆弱性診断の内製化や内製化後の運用・業務改善、内製化に伴う診断員教育、内製化におけるAI利活用推進といった支援も可能ですので、お困りのことがありましたらご相談いただければ幸いです。

P.S. 今回は汎用的な診断項目の策定プロセスに焦点を当てましたが、事業ドメインや機能に応じた診断項目の作成にも取り組んでおります。これまでの知見を基に様々なサービスや特有の機能を対象とした診断項目を500件以上作成しました。また、LLMを用いて診断対象機能や仕様、実装等の情報を基に診断項目を作成する取り組みなども行っており、脆弱性診断の際は汎用的な診断項目だけでなく診断対象に応じた検証を実施しております。それについては、機会があればまた別のブログでご紹介させていただきます。

望月岳